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DETAILED ACTION 



Withdraw of Finality 



In view of the applicant's arguments filed on May 9, 2003 (paper no. 15) and the subsequent 
telephone interview on June 3, 2003 (paper no. 17), PROSECUTION IS HEREBY REOPENED. A new 
grounds rejection is set forth below. 



Claims 1-19 and 37-48 are rejected under the judicially created doctrine of obviousness-type 
double patenting as being unpatentable over either claims 1-59 of Brenner et al. 5 U.S. Patent 6,004, 21 1 
(Dec. 21, 1999) (hereinafter ''Brenner '211") or claims 1-132 of Brenner et al., U.S. Patent 5,830,068 
(Nov. 3, 1998) (hereinafter "Brenner 068") each Dan Wagner et al., 'The Human Factors Design Guide', 
DOT/FAA/CT-96/1 (Jan. 15, 1996) (hereinafter '7/FDG") and Lawler et al., U.S. 5,805,763 (Sep. 8, 
1998).. 

Brenner '068 and Brenner '211 disclose "off-track" wagering systems having an interactive user 
interface allowing users to review racing information and place bets. See abstract. The through the 
interface, users may select a desired racetrack and race and view odds, pools, and payoff amounts for a 
variety of wager types. See id To place a wager, the user selects a wager type, wager amount, and the 
desired runners. See id. Account information can be reviewed and the user can transfer funds from a 
bank account to an account used for wagering. See id. Racing videos can be viewed while the user 
reviews odds and places bets. See id. Alternatively, video clips of past races can be ordered. See id. 
Related advertisements can be presented using text or video clips. See id. Merchandise may be ordered 
interactively. See id Finally, information regarding system usage may be gathered. See id 



Double Patenting 
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In regards to claims 1, 19, 37 and 48: Brenner '068 and Brenner '211 teach the following 
features: 

a. Allowing a user to create and place a wager for a given race by interacting with a 
plurality of wager creation options. See '068, 1, 2, 33, 35, 48-57, See '211, claims 1, 19, 
37, 58 and 59 

b. Providing the user with an option to record the given race while the user is 
interacting with a plurality of wager creation options. See '068, claims 69,89, 
92, 93, 96, 100, 125. See '211, claims 1, 19, 37, 58 and 59. 

c. Recording the given race on a video recording device. See '068, claims 94, 125. 
See '211, claims 2, 5, 36, 37 and 53. 

Brenner '068 teaches all the features of the claims except the particular combination of automatically 
prompting the user to decide whether to record the race while interacting the plurality of wager creation 
options. Regardless of the deficiency, this feature would have been obvious to an artisan in view of the 
HFDG and Lawler. 

The HFDG provides reference information to assist in the selection, analysis, design, 
development, and evaluation of new and modified Federal Aviation Administration (FAA) systems and 
equipment. See abstract. A preliminary edition was a draft standard developed at the Human Factors 
Laboratory of the FAA Technical Center. See id. This 1996 edition converts the preliminary draft 
document to a guide and incorporates expert comments that were collected in 1994 and 1995 from 
selected reviewers. See id. It is primarily focused on FAA ground systems and equipment such as those 
that are managed and maintained by Airway Facilities. See id. This guide covers a broad range of human 
factors topics that pertain to automation, maintenance, human interfaces, workplace design, 
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documentation, system security, safety, the environment, and anthropometry. See id. The document also 
includes extensive human-computer interface guidance. 

Section 8 of the HFDG is directed particularly to human-computer interfaces. See §8. J. This 
section contains criteria and guidelines governing human-computer interfaces. The topics covered 
include: modes of human-computer interaction, basic screen design, windowing, data entry, data display, 
user guidance, data communication, input devices, and accommodating people with disabilities. See id. 
In regards to the claimed invention, the HFDG teaches fundamental concepts of interactive user interfaces 
that were within the knowledge of an artisan at the time of the invention. Portions of the section which 
are relevant to the applicant's claims are provided below: 



8.1 USER-COMPUTER INTERACTION 
8.1.1 General 

8.1.1.1 Consistent control actions. 

Interactive control actions should be consistent in form, means, and consequence from one transaction to 
another, from one task to another, and from one application to another. Discussion. This guideline is 
extremely important for users of multiple applications. For example, if a user of a system being designed or 
selected must control several diverse operating systems or inconsistent control functions, then high error 
rates, extensive training, and low human reliability may be a consequence. 

8.1.1.2 System matched to user abilities. 

Interactive control systems should be adaptable to individual differences and should accommodate the 
variety of user abilities expected, whether novice or expert. If applicable, systems and applications should 
provide relatively helpful or self-explanatory operations for novice or infrequent users, and relatively 
efficient operations for experienced users. 

8.1.1.6 Simplicity. 

Interactive control shall be simple, flexible, and adaptive, as well as consistent and compatible with the 
lowest anticipated user skill level. Interactive control shall be logical in terms of user task sequences and 
functions. 

8.1.1.7 Minimal user actions. 

Interactive control logic should permit completion of a task with the minimum number of actions, consistent 
with user abilities. 

8.1.1.12 Minimal memory load. 

The short-term memory requirements on users should be minimized by such means as making displays and 
interactive sequences self-evident and by providing on-line help and tutorials. 

8. 1.1.24 Prompts. 

If a user must perform several actions to complete a task, the application should prompt the user with the 
actions that need to be performed. 



8.1.6 Transaction and control options 
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8. 1.6.3 Prompting control entries. 

The system or application shall provide the user whatever information is required to guide control entries. 
Examples. Prompts may be incorporated into a display at any point in a transaction sequence that will be 
helpful, or prompts may appear in response to a request for help. The selected prompts must be used 
consistently. 

8.1.6.4 List of basic control options. 

A list of basic control options that are always available to a user shall be easily displayable. This list can 
serve as a "home base" or starting point for control entries. An example is the system-level menu. 

8.1.6.7 Option presentation. 

The options presented in a list of basic options should be grouped, labeled, and ordered according 

to their: (1) logical function, (2) sequence, (3) frequency, or (4) criticality of use. If these ordering schemes 

are in conflict, default to the higher level order. 



8.1.8 Interaction method 

8.1.8.1 Selection of interaction type. 

The interaction type shall be selected to be appropriate to the task requirements, the characteristics of the 
system, and the abilities of the users. The appropriateness of the major types of interaction for these 
requirements, characteristics, and abilities are listed here and summarized in exhibit 8. 1 .8. 1 . 

8.1.8.3 Hierarchical levels. 

If hierarchical levels are used to control a process or sequence, the number of levels shall be 
niinimized. Display and input formats shall be similar within levels, and the system shall indicate the 
current position within a sequence (see also paragraph 8.1 . 1 1 .3.4). 

8.1.11 Menus and menu selection 

The use of menus as an interaction method is widespread, often in conjunction with other methods, direct 
manipulation, in particular. Menus are usable with little or no training on the part of the user. If the 
meanings of the options are clear, the user can be guided step-by-step through an application. Menus do 
have some disadvantages, however, they can slow down an experienced user, they can occupy a 
considerable amount of display space; and, in complex sequences, users may become lost in the menu 
structure. 

8. 1. 1 1. 1.6 Number of options. 

The number of options in a menu should not be more than ten or less than three (same as paragraph 
8.3.7.3.6). 

8. 1. 1 1. 1.7 Display of all options. 

A menu shall display explicitly and completely all options available to a user at the current step 
in a transaction sequence. 

8.1.11.1.11 Shortcuts for experienced users. 

Experienced users should have a way to bypass the menu structure for frequently accessed options (see also 
paragraph 8.1.11.3.13). 

8. 1. 1 1.3 Hierarchical menus 

Large or complex menus can be presented as hierarchical menus. Definition. A hierarchical menu is a 
large menu that is organized as a multi-level, branching structure of smaller menus in which an option in a 
higher level menu is the name of another menu at the next lower level. The options in the lowest level 
menus are such things as commands or values; they are not the names of other menus. 

8.1.11.3.1 When to use. 

Hierarchical menus should be used if there are many options (more than 10), and the options can be 
organized in a branching structure. 
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8.1.11.3.4 Minimum number of levels. 

A hierarchical menu structure should rmmmize the number of selections required to reach the desired 
option. This implies the use of broad, shallow structures as opposed to narrow, deep ones. 

8.1.11.3.5 Easy selection of important options. 

Hierarchical menus should permit immediate user access to critical or frequently selected options. 

8. 1. 1 1.3. 13 Bypassing menu selections. The system or application should allow a user to bypass a series of 
menu selections by making an equivalent command entry (see also paragraph 8. 1 . 1 1 . 1. 1 1). 



8.1.14 Query and natural language 

This section contains criteria and guidelines for database queries. 

Definitions. A data base is a set of interrelated data stored in a computer. A query is the process of 
specifying, locating, and retrieving data matching specified characteristics from a data base. 

8. 1. 14.2 Query screen design 

8.1.14.2.1 Applicable criteria and guidelines. 

Query screen design shall conform to the criteria and guidelines in sections 8.3, 8.4, and 8.5. 

8.1.14.2.2 Relevant information only. 

Query screens should include only information that is relevant to the task, that is, information necessary to 
perform actions, make decisions, or answer questions. 

8.1.14.2.3 Frequently-used information. 

The most frequently used information should be located in the upper left portion of a 
screen and, if multiple screens are involved, on the first screen 
or screens. 

8.1.14.4.2 Minimal user effort 

The number of keystrokes required of users should be miriimized. 

8.1.15 Graphical controls 

Icons may be used to represent operations, processes, and data structures graphically, and they may be used 

as a means of exercising control over system functions, components, and data 

structures. 



8.2 BASIC SCREEN DESIGN AND OPERATION 

Screen design refers to the way information is arranged and presented on a display screen. Different 
systems and applications can perform a great variety of tasks. Some systems rely heavily on data bases and 
do not require immediate user response to information displayed on their screens. Other systems, such as 
control systems, require that the users make immediate decisions and issue commands based on information 
displayed to them. The designer needs to understand the primary function of the system being developed to 
provide an effective screen design. 

8.2.1 Principles, features, and functions 

8.2.1.1 General principles 

8.2.1.1.1 Simplicity. 

Information should be presented simply and in a well-organized manner. Ways to achieve simplicity 
include the following: 

a. The screen should appear to be orderly and clutter-free. 

b. Information should be presented in consistent, predictable locations. 

c. The language used should be plain and simple. 

d. The means for moving around the screen and to related screens should be simple. 

e. Interrelationships should be indicated clearly. 
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8.2.1.1.2 Logical grouping. 

Data items on a screen should be grouped on the basis of some logical principle. 

8.2.1.1.3 Minimal movement. Screens should be designed to minimize both eye movement and pointer 
movement. 

8.2.1.1.4 What information to display. 

The information to be displayed should be prioritized so that the most important or critical information can 
be displayed all the time, and less important or critical information can be displayed upon a user's request 

8.2.1.8.1 Minimizing the user's short-term memory load. 

Windows should be designed to minimize the short-term memory load placed on a user as he or she 
performs the task called for by the window. A window should contain all relevant information and should 
allow a user to complete the task without having to refer to additional information. 

8.2. 1.9.2 Matching window layout to users' "Natural" patterns. Window layout should conform to 
users' natural scanning order and probable selection sequences. Usually, the order will be from left to right 
and top to bottom. For example, in button sets and menus, the most frequent choice should appear in the 
leftmost or top position. 

8.2. 1.9.3 Minimal user effort 

The amount of pointer movement and the number of keystrokes required to complete a task should be 
minimized. 



8.3 WINDOWING 

Windows provide a convenient and easy to use means of organizing many of the interactive aspects of a 
system or application and presenting them to a user. 

Definition. A window is a rectangular area on the screen that provides a visual means for interaction with 
an application. Applications also use windows to provide information to the user. This section contains 
criteria and guidelines for window components, appearance, and states, for window controls and operations, 
for menus and text in windows, and for a variety of special purpose windows. 

Caveat. Much of the material contained in section 8.6 may be very closely tied to a particular scheme or 
model for implementing windows and handling window management operations. The scheme being alluded 
to in any one rule may not be the only way of handling windows, nor is it the only recommended, approved, 
or acceptable way of doing so. To imply otherwise might violate the intent (if not the letter) of paragraph 
4, 1 . 10 of this standard. The authors of this guideline have, to the extent possible, removed guidelines that 
would have eliminated or restricted a particular window management system. For example, the OSF/Motif, 
Open Look, Apple Macintosh, and Microsoft Windows window management systems all offer similar, but 
slightly differing models for accomplishing many of the same windowing functions. To prematurely focus 
upon and exclusively adopt any single one of these management systems would do a disservice to the users 
of this proposed guideline. However, to simply strike out all such implementation-specific referential 
paragraphs within this section would result in removing a great deal of potentially helpful or useful design 
guidance information. The editors of these guidelines have chosen to retain these paragraphs for the 
potential value they might offer as examples of at least one acceptable method of implementing a windows 
operating environment. 

8.3.3 Window controls 

This section contains criteria and guidelines for window controls. Definitions. A control is any object that 
allows a user to perform an action. Controls include buttons, menu options, settings, sliders, text fields, and 
check boxes. A push button is a control that appears as a bounded area (for example, a rectangle or oval) 
on a window. 

8.3. 12.2 Data entry windows 



8.3.12.2.1 Data entry window elements. 
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A data entry window should contain: (1 ) a title that describes the purpose or contents of the window, (2) a 
set of labeled fields, (3) vertical or horizontal scroll bars or both, if the contents do not fit in the window's 
working area, and (4) controls appropriate to the task. 

Definition. A data entry window is a window that contains a set of labeled fields for entering, changing, 
and deleting data. It may also contain labeled data display fields, which a user cannot change. 

8.3.12.2.2 Data window organization. The organization of a data entry window should be consistent with 
the task it represents. For example, data fields should be arranged by sequence of use, frequency of use, or 
importance, with related fields grouped together and separated from unrelated fields. If users will enter data 
from hard copy forms, the data entry field organization should correspond to that of the hard copy. 

8.3.12.2.3 Multipage data entry windows. 

If the contents of a set of data entry fields do not fit the window's working area, a, the window should 
provide users the ability to page, scroll, or both through the entire set, and b. if the fields are arranged in 
rows, columns, or both, the labels of the rows or columns should remain in place when the rows or columns 
scroll or page. 

8.3.12.2.4 Push buttons in data entry windows. 

If a data entry window contains push buttons, the buttons should be placed in a row at the bottom of the 
working area, visually separated from the data fields. 

8.3.12.2.5 Controls for data entry windows. 

A data entry window should contain the controls appropriate to the task. 



8.4 DATA ENTRY 

Data entry refers to user actions involving the input of data into a computer system, and the system's 
response to the user actions. The data entry methods covered in this section are: (1) selection from menus, 
(2) form filling, (3) direct manipulation, and (4) the keyboard entry of text Additional topics covered in this 
section include the entry of tabular and graphic data, and the validation of entered data 

8.4.1 Menus 

Menus are often useful in data entry, for example, to list files that may be retrieved, or to list the acceptable 
entries for a field in a form. Menus of this sort are often too long to display in their entirety. In that case, a 
portion of the menu is displayed and a scrolling capability is provided. 

8.4.1.2 Hierarchical menus 

8.4.1.2.1 When to use. 

Hierarchical menus should be used if the number of options is more than ten and the options can be 
organized into a meaningful hierarchy. Note. A hierarchical structure may be more cumbersome and 
keystroke intensive than a longer, single-level structure. Thus, if a long list of options is obviously and 
logically organized, it will be easier to use than a hierarchical structure. For instance, consider a list of type 
sizes numerically ordered or a long list font alternatives logically organized. 

8.4.1.2.2 Applicable rules. 

If hierarchical menus are used for data entry, they shall conform to the rules in section 8. 1 . 1 1 . 3. 
8.4.1.4 Pop-up menus 

Pop-up menus can be very useful in data entry. They can present to a user the permissible entries for a field, 
thus (1) eliminating the need for the user to remember the entries, (2) preventing invalid entries, and (3) 
ehminating potential typing errors. Definition. A pop-up menu is a menu that is associated with a 
particular object on a display, for example, a pop-up menu listing acceptable command options close to the 
immediate work area. This is particularly useful for large displays, where the work site may be relatively 
removed for the menu bar. 
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As provided above, the HFDG describes fundamental goals for implementing effective human-computer 
interfaces. In light of these goals, more specific prior art is discussed below. 

Lawler discloses an analogous system having an interactive user interface allowing users to 
search and automatically record broadcast events. Similar to Brenner, wherein users collect race program 
information and place orders for racing videos, Lawler allows users to collect entertainment program 
information and place orders for event videos. See fig. 3; col 1:45-2:40. The system provides on- 
demand delivery of event videos ranging from brief clips to full length motion pictures. See col 4:23-26. 
Users may order videos of past, present or future events. See fig. 7. In specific regards to the claims, 
Lawler describes automatically prompting the user to decide whether to record an event while interacting 
the plurality of program selection menus. See fig. 4(a) (b), 6-10. As a result, the system allows users to 
more quickly and easily identify and select events using an interactive user-interface and to designate the 
selected event for recording. See col. 1:45-50. 

In view of the HFDG and Lawler, it would have been obvious to one of ordinary skill in the art at 
the time of the invention to modify the off-track wagering system disclosed by Brenner to add the feature 
of automatically prompting the user to decide whether to record the race while interacting the plurality of 
wager creation options. Brenner discloses an interactive human-computer interface for off-track betting 
wherein a menu allows users the option of record racing videos. Lawler describes automatically 
prompting a user to decide whether to record an event while interacting with a plurality of program 
selection menus and thereby more easily designate a selected event for recording. See col 1:45-50. See 
fig- 4(a) (b), 6-10. As suggested by the HFDG, modifying Brenner the add the feature would enhance the 
system's human-computer interface by (i) permitting completion of the task with the minimum number of 
actions; (ii) incorporating prompts into the display at points in a transaction sequence that will be helpful; 
(iii) including with the list of basic control option a selection that is always available to a user; (iv) 
presenting frequently used and/or critical option within the group of basic options; (v) displaying all 



Application/Control Number: 09/609,073 Page 1 0 

Art Unit: 3714 

options available to a user at the current step in a transaction sequence; (vi) providing experienced users a 
way to bypass the menu structure to execute the frequently accessed option; (vii) permitting immediate 
access to a critical and/or frequently selected option; (viii) prioritizing the display so that an important or 
critical information is displayed all the time; (ix) minimizing the amount of pointer movement and the 
number of keystrokes required for the user to complete the task; and (x) adapting the user interface to 
accommodate a variety of user abilities such that it offers relatively efficient operations for experienced 
users. Consequently the claims are unpatentable because they are obvious when the prior art is taken as a 
whole by an artisan at a time prior to the invention. 

In further regards to the claim 2: Lawler additionally describes allowing the user to selecting 
"order" or "cancel" in response to the option to select the given race. See Jig. 10; col. 10:60-64. This is 
equivalent to the claimed feature of selecting "yes" or "no". Although the terminology is different, the 
method is the same. 

In further regards to the claim 3: Lawler additionally suggests recording the race in response to 
the user selecting "yes" or "no". See id. 

In further regards to the claims 4 and 46: Lawler additionally describes storing the event in a 
personal archive. See col. 13:26-37. 

In further regards to the claim 5 : Lawler additionally describes locating the personal event archive 
on the user's equipment. See col. 2:14-23. 
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In further regards to dependent claim 6 and 45: Brenner '068 and Brenner '211 additionally 
describe storing race video at a remote location. See '068, claims 6, 32, 42. See '211, claims 2, 7. 
Alternatively, Lawler additionally describes locating the personal archive remotely from the user's 
equipment. See col 2:24-35, 13:26-37. 

In further regards to dependent claims 7 and 47: Brenner '068 and Brenner '211 additionally 
describe allowing users to access and view stored race recordings on a display device. See '068, 24-29. 
See '211, claims 4, 24. Alternatively, Lawler additionally describes allowing users to access and view 
stored race recordings on a display device. See col. 2:24-35, 13:26-37. 

In further regards to dependent claims 8-10: Lawler additionally describes allowing the user to 
search for videos based on search criteria including time, date, length, subject. See 7:10-18. 

In further regards to dependent claims 1 1, 38 and 40: Brenner '068 and Brenner '211 
additionally describe using television equipment as user equipment. See '068, 16, 35, 45, 78. See '211, 
claim 14, 29, 46, 49. Alternatively, Lawler additionally describes using television equipment as user 
equipment. See fig. 1. 

In regards to claims 12 and 41: Brenner '068 and Brenner '211 additionally describe recording a 
given race with a video cassette recorder. See '068, claims 94, 125. See '211, claims 2, 5, 36, 37 and 53. 
Alternatively, Lawler describes recording a given event with a video cassette recorder. See col. 1:33- 
42,3:36-39. 
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In regards to claim 13 and 42: Lawler additionally describes Recording the given race on 
a videocassette recorder or, alternatively, other digital recording device. See col 3:28-67. 



In further regards to dependent claims 14 and 43: Brenner '068 and Brenner '211 additionally 
describe employing a computer as user equipment. Notably, the examiner interprets to claims use of 
"terminal" to include computers. See '068, claims 1, 2, 36. See '21 l t claims 14, 37, 58, 59. 
Alternatively, Lawler additionally describes employing a computer as user equipment. See fig. 2. 

In further regards to the claims 15 and 44: Lawler additionally describes employing telephone 
equipment as user equipment. See col 5:29-36. 

In further regards to dependent claim 16: Brenner '068 and Brenner '211 additionally describe 
recording the race in real-time. See '068, claims 96, 125. See '211, claims 1, 4. Alternatively, Lawler 
additionally describes recording the events in real-time. See fig. 7. 

In further regards to dependent claim 17 and 47: Brenner '068 and Brenner '211 additionally 
describes recording the race after it has taken place. See '068, claims 96, 125. See '211, claims 1, 4. 
Alternatively, Lawler additionally describes recording the race after it has taken place. See fig. 7. 

In further regards to dependent claim 18: Brenner '068 and Brenner '211 additionally describes 
charging a fee for recording a given race. See '068, claims 75, 102. See '211, claims 12, 37, 46. 
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In further regards to the claim 39: Lawler additionally describes locating control circuitry in a 
"set-top box". See fig. 1. 



The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 
rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art 
are such that the subject matter as a whole would have been obvious at the time the invention was made to a 
person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 

Claims 1-19 and 37-48 are rejected under 35 U.S.C. 103(a) as being unpatentable over Brenner, 
U.S. 5,830,068 (Nov. 3, 1998) in view of Dan Wagner et al., e The Human Factors Design Guide', 
DOT/FAA/CT-96/1 (Jan. 15, 1996) (hereinafter "HFDG") and Lawler et al., U.S. 5,805,763 (Sep. 8, 
1998). 

Brenner discloses an "off-track" wagering system having an interactive user interface allowing 
users to review racing information and place bets. See abstract The through the interface, users may 
select a desired racetrack and race and view odds, pools, and payoff amounts for a variety of wager types. 
See id. To place a wager, the user selects a wager type, wager amount, and the desired runners. See id. 
Account information can be reviewed and the user can transfer funds from a bank account to an account 
used for wagering. See id. Racing videos can be viewed while the user reviews odds and places bets. 
See id. Alternatively, video clips of past races can be ordered. See id. Related advertisements can be 
presented using text or video clips. See id. Merchandise may be ordered interactively. See id. Finally, 
information regarding system usage may be gathered. See id. 



Claim Rejections - 35 USC § 103 



In regards to claims 1, 19, 37 and 48: Brenner teaches the following features: 
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d. 



Allowing a user to create and place a wager for a given race by interacting with a 



plurality of wager creation options. 



e. 



Providing the user with an option to record the given race while the user is 



interacting with a plurality of wager creation options. See fig. 34(596) 



f. 



Recording the given race on a video recording device. See id. 



Brenner '068 teaches all the features of the claims except the particular combination of automatically 
prompting the user to decide whether to record the race while interacting the plurality of wager creation 
options. Regardless of the deficiency, this feature would have been obvious to an artisan in view of the 
HFDG and Lawler. 

The HFDG provides reference information to assist in the selection, analysis, design, 
development, and evaluation of new and modified Federal Aviation Administration (FAA) systems and 
equipment. See abstract. A preliminary edition was a draft standard developed at the Human Factors 
Laboratory of the FAA Technical Center. See id This 1996 edition converts the preliminary draft 
document to a guide and incorporates expert comments that were collected in 1994 and 1995 from 
selected reviewers. See id. It is primarily focused on FAA ground systems and equipment such as those 
that are managed and maintained by Airway Facilities. See id. This guide covers a broad range of human 
factors topics that pertain to automation, maintenance, human interfaces, workplace design, 
documentation, system security, safety, the environment, and anthropometry. See id. The document also 
includes extensive human-computer interface guidance. 

Section 8 of the HFDG is directed particularly to human-computer interfaces. See §8.1. This 
section contains criteria and guidelines governing human-computer interfaces. The topics covered 
include: modes of human-computer interaction, basic screen design, windowing, data entry, data display, 
user guidance, data communication, input devices, and accommodating people with disabilities. See id. 
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In regards to the claimed invention, the HFDG teaches fundamental concepts of interactive user interfaces 
that were within the knowledge of an artisan at the time of the invention. Portions of the section which 
are relevant to the applicant's claims are provided below: 



8.1 USER-COMPUTER INTERACTION 
8.1.1 General 

8.1.1.1 Consistent control actions. 

Interactive control actions should be consistent in form, means, and consequence from one transaction to 
another, from one task to another, and from one application to another. Discussion. This guideline is 
extremely important for users of multiple applications. For example, if a user of a system being designed or 
selected must control several diverse operating systems or inconsistent control functions, then high error 
rates, extensive training, and low human reliability may be a consequence. 

8.1.1.2 System matched to user abilities. 

Interactive control systems should be adaptable to individual differences and should accommodate the 
variety of user abilities expected, whether novice or expert If applicable, k systems and applications should 
provide relatively helpful or self-explanatory operations for novice or infrequent users, and relatively 
efficient operations for experienced users. 

8.1.1.6 Simplicity. 

Interactive control shall be simple, flexible, and adaptive, as well as consistent and compatible with the 
lowest anticipated user skill level. Interactive control shall be logical in terms of user task sequences and 
functions. 

8.1.1.7 Minimal user actions. 

Interactive control logic should permit completion of a task with the minimum number of actions, consistent 
with user abilities. 

8.1.1.12 Minimal memory load. 

The short-term memory requirements on users should be rmnimized by such means as making displays and 
interactive sequences self-evident and by providing on-line help and tutorials. 

8.1.1.24 Prompts. 

If a user must perform several actions to complete a task, the application should prompt the user with the 
actions that need to be performed. 



8.1.6 Transaction and control options 

8.1.6.3 Prompting control entries. 

The system or application shall provide the user whatever information is required to guide control entries. 
Examples. Prompts may be incorporated into a display at any point in a transaction sequence that will be 
helpful, or prompts may appear in response to a request for help. The selected prompts must be used 
consistently. 

8.1.6.4 List of basic control options. 

A list of basic control options that are always available to a user shall be easily displayable. This list can 
serve as a "home base" or starting point for control entries. An example is the system-level menu. 

8.1.6.7 Option presentation. 

The options presented in a list of basic options should be grouped, labeled, and ordered according 

to their: (1) logical function, (2) sequence, (3) frequency, or (4) criticality of use. If these ordering schemes 

are in conflict, default to the higher level order. 
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8.1.8 Interaction method 

8.1.8.1 Selection of interaction type. 

The interaction type shall be selected to be appropriate to the task requirements, the characteristics of the 
system, and the abilities of the users. The appropriateness of the major types of interaction for these 
requirements, characteristics, and abilities are listed here and summarized in exhibit 8. 1 .8. 1 . 

8.1.8.3 Hierarchical levels. 

If hierarchical levels are used to control a process or sequence, the number of levels shall be 
minimized. Display and input formats shall be similar within levels, and the system shall indicate the 
current position within a sequence (see also paragraph 8.1 .1 1 .3.4). 

8.1.11 Menus and menu selection 

The use of menus as an interaction method is widespread, often in conjunction with other methods, direct 
manipulation, in particular. Menus are usable with little or no training on the part of the user. If the 
meanings of the options are clear, the user can be guided step-by-step through an application. Menus do 
have some disadvantages, however, they can slow down an experienced user, they can occupy a 
considerable amount of display space; and, in complex sequences, users may become lost in the menu 
structure. 

8. 1. 1 1. 1.6 Number of options. 

The number of options in a menu should not be more than ten or less than three (same as paragraph 
8.3.7.3.6). 

8.1.11.1.7 Display of all options. 

A menu shall display explicitly and completely all options available to a user at the current step 
in a transaction sequence. 

8.1.11.1.11 Shortcuts for experienced users. 

Experienced users should have a way to bypass the menu structure for frequently accessed options (see also 
paragraph 8.1.11.3.13). 

8. 1.1 1.3 Hierarchical menus 

Large or complex menus can be presented as hierarchical menus. Definition. A hierarchical menu is a 
large menu that is organized as a multi-level, branching structure of smaller menus in which an option in a 
higher level menu is the name of another menu at the next lower level. The options in the lowest level 
menus are such things as commands or values; they are not the names of other menus, 

8.1.11.3.1 When to use. 

Hierarchical menus should be used if there are many options (more than 10), and the options can be 
organized in a branching structure. 

8.1.11.3.4 Minimum number of levels. 

A hierarchical menu structure should niinimize the number of selections required to reach the desired 
option. This implies the use of broad, shallow structures as opposed to narrow, deep ones. 

8.1.11.3.5 Easy selection of important options. 

Hierarchical menus should permit immediate user access to critical or frequently selected options. 

8. 1. 1 1.3. 13 Bypassing menu selections. The system or application should allow a user to bypass a series of 
menu selections by making an equivalent command entry (see also paragraph 8.1.11.1.11). 



8.1.14 Query and natural language 

This section contains criteria and guidelines for database queries. 

Definitions. A data base is a set of interrelated data stored in a computer. A query is the process of 
specifying, locating, and retrieving data matching specified characteristics from a data base. 
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8.1.14.2 Query screen design 

8.1.14.2.1 Applicable criteria and guidelines. 

Query screen design shall conform to the criteria and guidelines in sections 8.3, 8.4, and 8.5. 

8.1.14.2.2 Relevant information only. 

Query screens should include only information that is relevant to the task, that is, information necessary to 
perform actions, make decisions, or answer questions. 

8.1.14.2.3 Frequently-used information. 

The most frequently used information should be located in the upper left portion of a 
screen and, if multiple screens are involved, on the first screen 
or screens. 

8.1.14.4.2 Minimal user effort 

The number of keystrokes required of users should be niinimized. 
8. 1. IS Graphical controls 

Icons may be used to represent operations, processes, and data structures graphically, and they may be used 

as a means of exercising control over system functions, components, and data 

structures. 



8.2 BASIC SCREEN DESIGN AND OPERATION 

Screen design refers to the way information is arranged and presented on a display screen. Different 
systems and applications can perform a great variety of tasks. Some systems rely heavily on data bases and 
do not require immediate user response to information displayed on their screens. Other systems, such as 
control systems, require that the users make immediate decisions and issue commands based on information 
displayed to them. The designer needs to understand the primary function of the system being developed to 
provide an effective screen design. 

8.2.1 Principles, features, and functions 

8.2.1.1 General principles 

8.2.1.1.1 Simplicity. 

Information should be presented simply and in a well-organized manner. Ways to achieve simplicity 
include the following: 

a. The screen should appear to be orderly and clutter-free. 

b. Information should be presented in consistent, predictable locations. 

c. The language used should be plain and simple. 

d. The means for moving around the screen and to related screens should be simple. 

e. Interrelationships should be indicated clearly. 

8.2.1.1.2 Logical grouping. 

Data items on a screen should be grouped on the basis of some logical principle. 

8.2.1.1.3 Minimal movement. Screens should be designed to niinimize both eye movement and pointer 
movement. 

8.2.1.1.4 What information to display. 

The information to be displayed should be prioritized so that the most important or critical information can 
be displayed all the time, and less important or critical information can be displayed upon a user's request 

8.2.1.8.1 Minimizing the user's short-term memory load. 

Windows should be designed to minimize the short-term memory load placed on a user as he or she 
performs the task called for by the window. A window should contain all relevant information and should 
allow a user to complete the task without having to refer to additional information. 
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8.2.1.9.2 Matching window layout to users' "Natural" patterns. Window layout should conform to 
users' natural scanning order and probable selection sequences. Usually, the order will be from left to right 
and top to bottom. For example, in button sets and menus, the most frequent choice should appear in the 
leftmost or top position. 

8.2.1.9.3 Minimal user effort 

The amount of pointer movement and the number of keystrokes required to complete a task should be 
nunimized. 



8.3 WINDOWING 

Windows provide a convenient and easy to use means of organizing many of the interactive aspects of a 
system or application and presenting them to a user. 

Definition. A window is a rectangular area on the screen that provides a visual means for interaction with 
an application. Applications also use windows to provide information to the user. This section contains 
criteria and guidelines for window components, appearance, and states, for window controls and operations, 
for menus and text in windows, and for a variety of special purpose windows. 

Caveat. Much of the material contained in section 8.6 may be very closely tied to a particular scheme or 
model for implementing windows and handling window management operations. The scheme being alluded 
to in any one rule may not be the only way of handling windows, nor is it the only recommended, approved, 
or acceptable way of doing so. To imply otherwise might violate the intent (if not the letter) of paragraph 
4. 1 . 10 of this standard. The authors of this guideline have, to the extent possible, removed guidelines that 
would have eliminated or restricted a particular window management system. For example, the OSF/Motif, 
Open Look, Apple Macintosh, and Microsoft Windows window management systems all offer similar, but 
slightly differing models for accomplishing many of the same windowing functions. To prematurely focus 
upon and exclusively adopt any single one of these management systems would do a disservice to the users 
of this proposed guideline. However, to simply strike out all such implementation-specific referential 
paragraphs within this section would result in removing a great deal of potentially helpful or useful design 
guidance information. The editors of these guidelines have chosen to retain these paragraphs for the 
potential value they might offer as examples of at least one acceptable method of implementing a windows 
operating environment. 

8.3.3 Window controls 

This section contains criteria and guidelines for window controls. Definitions. A control is any object that 
allows a user to perform an action. Controls include buttons, menu options, settings, sliders, text fields, and 
check boxes. A push button is a control that appears as a bounded area (for example, a rectangle or oval) 
on a window. 

8.3.12.2 Data entry windows 

8.3.12.2.1 Data entry window elements. 

A data entry window should contain: ( 1) a title that describes the purpose or contents of the window, (2) a 
set of labeled fields, (3) vertical or horizontal scroll bars or both, if the contents do not fit in the window's 
working area, and (4) controls appropriate to the task. 

Definition. A data entry window is a window that contains a set of labeled fields for entering, changing, 
and deleting data. It may also contain labeled data display fields, which a user cannot change. 

8.3.12.2.2 Data window organization. The organization of a data entry window should be consistent with 
the task it represents. For example, data fields should be arranged by sequence of use, frequency of use, or 
importance, with related fields grouped together and separated from unrelated fields. If users will enter data 
from hard copy forms, the data entry field organization should correspond to that of the hard copy. 

8.3.12.2.3 Multipage data entry windows. 

If the contents of a set of data entry fields do not fit the window's working area, a the window should 
provide users the ability to page, scroll, or both through the entire set, and b. if the fields are arranged in 
rows, columns, or both, the labels of the rows or columns should remain in place when the rows or columns 
scroll or page. 
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8.3.12.2.4 Push buttons in data entry windows. 

If a data entry window contains push buttons, the buttons should be placed in a row at the bottom of the 
working area, visually separated from the data fields. 

8.3.12.15 Controls for data entry windows. 

A data entry window should contain the controls appropriate to the task. 



8.4 DATA ENTRY 

Data entry refers to user actions involving the input of data into a computer system, and the system's 
response to the user actions. The data entry methods covered in this section are: ( 1 ) selection from menus, 
(2) form filling, (3) direct manipulation, and (4) the keyboard entry of text Additional topics covered in this 
section include the entry of tabular and graphic data, and the validation of entered data. 

8.4.1 Menus 

Menus are often useful in data entry, for example, to list files that may be retrieved, or to list the acceptable 
entries for a field in a form. Menus of this sort are often too long to display in their entirety. In that case, a 
portion of the menu is displayed and a scrolling capability is provided. 

8.4. 1.2 Hierarchical menus 

8.4.1.2.1 When to use. 

Hierarchical menus should be used if the number of options is more than ten and the options can be 
organized into a meaningful hierarchy. Note. A hierarchical structure may be more cumbersome and 
keystroke intensive than a longer, single-level structure. Thus, if a long list of options is obviously and 
logically organized, it will be easier to use than a hierarchical structure. For instance, consider a list of type 
sizes numerically ordered or a long list font alternatives logically organized. 

8.4.1.2.2 Applicable rules. 

If hierarchical menus are used for data entry, they shall conform to the rules in section 8. 1 . 1 1 .3. 
8.4.1.4 Pop-up menus 

Pop-up menus can be very useful in data entry. They can present to a user the permissible entries for a field, 
thus (1 ) eliminating the need for the user to remember the entries, (2) preventing invalid entries, and (3) 
eliminating potential typing errors. Definition, A pop-up menu is a menu that is associated with a 
particular object on a display, for example, a pop-up menu listing acceptable command options close to the 
immediate work area. This is particularly useful for large displays, where the work site may be relatively 
removed for the menu bar. 

As provided above, the HFDG describes fundamental goals for implementing effective human-computer 
interfaces. In light of these goals, more specific prior art is discussed below. 

Lawler discloses an analogous system having an interactive user interface allowing users to 
search and automatically record broadcast events. Similar to Brenner, wherein users collect race program 
information and place orders for racing videos, Lawler allows users to collect entertainment program 
information and place orders for event videos. See fig. 3; col. 1:45-2:40. The system provides on- 
demand delivery of event videos ranging from brief clips to full length motion pictures. See col 4:23-26. 



Users may order videos of past, present or future events. See fig. 7. In specific regards to the claims, 
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Lawler describes automatically prompting the user to decide whether to record an event while interacting 
the plurality of program selection menus. See fig. 4(a)(b), 6-10. As a result, the system allows users to 
more quickly and easily identify and select events using an interactive user-interface and to designate the 
selected event for recording. See col. 1:45-50. 

In view of the HFDG and Lawler, it would have been obvious to one of ordinary skill in the art at 
the time of the invention to modify the off-track wagering system disclosed by Brenner to add the feature 
of automatically prompting the user to decide whether to record the race while interacting the plurality of 
wager creation options. Brenner discloses an interactive human-computer interface for off-track betting 
wherein a menu allows users the option of record racing videos. Lawler describes automatically 
prompting a user to decide whether to record an event while interacting with a plurality of program 
selection menus and thereby more easily designate a selected event for recording. See col. 1:45-50. . See 
fig- 4(a) (b), 6-10. As suggested by the HFDG, modifying Brenner the add the feature would enhance the 
system's human-computer interface by (i) permitting completion of the task with the minimum number of 
actions; (ii) incorporating prompts into the display at points in a transaction sequence that will be helpful; 
(iii) including with the list of basic control option a selection that is always available to a user; (iv) 
presenting frequently used and/or critical option within the group of basic options; (v) displaying all 
options available to a user at the current step in a transaction sequence; (vi) providing experienced users a 
way to bypass the menu structure to execute the frequently accessed option; (vii) permitting immediate 
access to a critical and/or frequently selected option; (viii) prioritizing the display so that an important or 
critical information is displayed all the time; (ix) minimizing the amount of pointer movement and the 
number of keystrokes required for the user to complete the task; and (x) adapting the user interface to 
accommodate a variety of user abilities such that it offers relatively efficient operations for experienced 
users. Consequently the claims are unpatentable because they are obvious when the prior art is taken as a 
whole by an artisan at a time prior to the invention. 
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In further regards to the claim 2: Lawler additionally describes allowing the user to selecting 
"order" or "cancel" in response to the option to select the given race. See fig. 10; col. 10:60-64. This is 
equivalent to the claimed feature of selecting "yes" or "no". Although the terminology is different, the 
method is the same. 

In further regards to the claim 3: Lawler additionally suggests recording the race in response to 
the user selecting "yes" or "no". See id. 

In further regards to the claims 4 and 46: Lawler additionally describes storing the event in a 
personal archive. See col. 13:26-37. 

In further regards to the claim 5: Lawler additionally describes locating the personal event archive 
on the user's equipment. See col. 2:14-23. 

In further regards to dependent claim 6 and 45: Brenner '068 additionally describes storing race 
video at a remote location. See 7:4-20, 27:23-39. . Alternatively, Lawler additionally describes locating 
the personal archive remotely from the user's equipment. See col. 2:24-35, 13:26-37. 

In further regards to dependent claims 7 and 47: Brenner '068 additionally describes allowing 
users to access and view stored race recordings on a display device. See fig. 1; 27:60-64. Alternatively, 
Lawler additionally describes allowing users to access and view stored race recordings on a display 
device. See col. 2:24-35, 13:26-37. 
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In further regards to dependent claims 8-10: Lawler additionally describes allowing the user to 
search for videos based on search criteria including time, date, length, subject. See 7:10-18, 

In further regards to dependent claims 11, 38 and 40: Brenner '068 additionally describes 
using television equipment as user equipment. See col 27:60-28:24. Alternatively, Lawler additionally 
describes using television equipment as user equipment. See Jig. 1. 

In regards to claims 12 and 41: Brenner '068 additionally describes recording a given race with a 
video cassette recorder. See col 27:65-28:15. Alternatively, Lawler describes recording a given event 
with a video cassette recorder. See col 1:33-42,3:36-39. 

In regards to claim 13 and 42: Lawler additionally describes Recording the given race on 
a videocassette recorder or, alternatively, other digital recording device. See col 3:28-67. 



In further regards to dependent claims 14 and 43: Brenner '068 additionally describes 
employing a computer as user equipment. Notably, the examiner interprets to claims use of "terminal" to 
include computers. See Jig. 1; col 7:21-34. Alternatively, Lawler additionally describes employing a 
computer as user equipment. See Jig. 2. 

In further regards to the claims 15 and 44: Lawler additionally describes employing telephone 
equipment as user equipment. See col 5:29-36. 
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In further regards to dependent claim 16: Brenner '068 additionally describes recording the race 
in real-time. See col. 6:55-62. Alternatively, Lawler additionally describes recording the events in real- 
time. See fig. 7 

In further regards to dependent claim 17 and 47: Brenner '068 additionally describes recording 
the race after it has taken place. See col. 26:65-27:22. Alternatively, Lawler additionally describes 
recording the race after it has taken place. See fig. 7. 

In further regards to dependent claim 18: Brenner '068 additionally describes charging a fee for 
recording a given race. See col. 27:33-39. 

In further regards to the claim 39: Lawler additionally describes locating control circuitry in a 
"set-top box". See fig. J. 

Response to Arguments 
Applicants arguments with respect to claims 1-19 and 37-48 have been considered but are moot 
in view of the new ground(s) of rejection. 



Any inquiry concerning this communication or earlier communications from the examiner should 
be directed to Steven Ashburn whose telephone number is 703 305 3543. The examiner can normally be 
reached on Monday thru Friday, 8:00 AM to 4:30 PM. If attempts to reach the examiner by telephone are 



Conclusion 
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unsuccessful, the examiner's supervisor, Tom Hughes can be reached on 703-308-1806. The fax phone 
numbers for the organization where this application or proceeding is assigned are 703 872 9302 for 
regular communications and 703 872 9303 for After Final communications. Any inquiry of a general 
nature or relating to the status of this application or proceeding should be directed to the receptionist 
whose telephone number is 703 308 1078. 




S.A. 

Jul y 15 ' 2003 MARK SAGER 

PRIMARY EXAMINER 



